Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000057_owner-urn-ietf _Wed Nov 6 09:31:28 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09106 for urn-ietf-out; Wed, 6 Nov 1996 09:31:28 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09101 for <[e-mail]>; Wed, 6 Nov 1996 09:31:26 -0500
Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA09820  (mail destined for [e-mail]); Wed, 6 Nov 96 09:31:20 -0500
Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:37 +0000
Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:17 +0000
Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:29:26 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 06 Nov 1996 14:31:36 +0000
To: [e-mail]
From: Bob Briscoe <[e-mail]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: Fisher Mark <[e-mail]>,
        "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

At 10:10 06/11/96 +0100, [e-mail] wrote:
>Bob,
>your point is well made that there needs to be some mechanism
>which allows an URN buyer to make a guess at how long the resolution
>service will stay in place.
>This is, I believe, properly part of a business arrangement.
>
>For an URN *user*, this may be interesting, but not vital.

A URN user is not just someone who clicks on one. It could also be someone
who publishes one (that you have published) to refer to your work in their
work. They need to know how long they should reliably use your URN.
Meta-data that any party might need is a proper candidate for holding in
infrastructure.

>It could easily(?) be solved as part of "metadata" on an URN,
>together with properties like the changability of the resource
>(the URN for "today's weather in Trondheim" has different properties
>than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07"
>(cloudy, rainy and about 3 degrees Celsius, BTW)).
>But I don't see it as a vital part of the infrastructure.

Certainly, I agree it could be metadata held somewhere else. However,
because it is meta-data owned directly by the URN (to be precise, the
portion of the name space the URN is part of) and because it has important
utility, if it *isn't* going to be held in the infrastructure, I believe it
is the job of this working group to say how it *would* be held.

If you leave this for 'ron (later on) as you suggest, you'll end up having
to have a URC for a URN resolution when URCs get sorted, then what URN do
you give the new URC? Then you'll need to hold the longevity of the
resolution for the new URN somewhere... how about another URC?

Get my drift?

>
>Using DNS TTL records for this is just broken; DNS TTLs are used
>to limit caching of name->address mapping, and in the NAPTR proposal,
>they should be a fraction of the time one expects to have advance
>warning of a server relocation or mapping restructure.
>Normal TTLs are on the order of 3 days, and are usually reduced to less
>than 1 day before serious network reorganizations.

I didn't mean that. I used the term TTL to mean a new Time To Live (of the
resolution availability), not the specific TTL that DNS uses. Sorry again
for being sloppy with my terminology.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm